Conversation
|
|
||
| 2022年2月に [GitHub が Markdown の Mermaid ネイティブサポート](https://github.blog/developer-skills/github/include-diagrams-markdown-files-mermaid/) を発表してから一気に広まった印象があり、現在は GitHub・GitLab・Notion などが標準対応しています。クライアントサイド JS 単独で動く身軽さと相まって、Diagrams as Code の中心的存在です。 | ||
|
|
||
| 同じく「図をテキストで書く」系としては [PlantUML](https://plantuml.com/) が先行しています。PlantUML は Java ベースで開発されていて、配置図・タイミング図・ユースケース図など UML 記号の網羅性が高いのが特徴です。ただしレンダリングにサーバサイド環境を要する分、GitHub や社内 Wiki にそのまま貼って読ませる気軽さは Mermaid の方がある、という棲み分けかなと思います。フューチャーでも過去に [PlantUML 用のカラーテーマ(toy / vibrant / mars)を自作して公式テーマに採用された](https://future-architect.github.io/articles/20211108a/) 経緯があり、社内では Mermaid.js も PlantUML もよく使われています。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "が" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "が"
- "が"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| 2022年2月に [GitHub が Markdown の Mermaid ネイティブサポート](https://github.blog/developer-skills/github/include-diagrams-markdown-files-mermaid/) を発表してから一気に広まった印象があり、現在は GitHub・GitLab・Notion などが標準対応しています。クライアントサイド JS 単独で動く身軽さと相まって、Diagrams as Code の中心的存在です。 | ||
|
|
||
| 同じく「図をテキストで書く」系としては [PlantUML](https://plantuml.com/) が先行しています。PlantUML は Java ベースで開発されていて、配置図・タイミング図・ユースケース図など UML 記号の網羅性が高いのが特徴です。ただしレンダリングにサーバサイド環境を要する分、GitHub や社内 Wiki にそのまま貼って読ませる気軽さは Mermaid の方がある、という棲み分けかなと思います。フューチャーでも過去に [PlantUML 用のカラーテーマ(toy / vibrant / mars)を自作して公式テーマに採用された](https://future-architect.github.io/articles/20211108a/) 経緯があり、社内では Mermaid.js も PlantUML もよく使われています。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "も" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "も"
- "も"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| frontmatter に `config:` を書くのと見た目の結果は同じです。 | ||
|
|
||
| - コード本体と一緒に持ち回りたい → frontmatter に書く。移植性が高まる |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "に" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "に"
- "に"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
| - コード本体と一緒に持ち回りたい → frontmatter に書く。移植性が高まる | ||
| - Live Editor 内だけで良い → Config タブに書く。コード本体をスリムに見せることができる | ||
|
|
||
| ちなみに、`config` を変更してもURLは反映されるので、単にMermaid Live Editorで閉じてやり取りする場合はどちらを使っても大差ないです。こだわりがなければ、私は移植性が高いfrontmatter記述が良いと思いますが、どうでしょうか? |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "が" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "が"
- "が"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| ## 3. 時計アイコンで履歴パネルを開きスナップショット保存 | ||
|
|
||
| 画面上部の GitHub アイコンの隣にある白黒の🕓️アイコンをクリックすると、履歴パネルが開きます。`Save Current State` を押すと現在の編集状態がスナップショットとして残り、後から一覧から選んで戻せます。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "から" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "から"
- "から"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
| } | ||
| ``` | ||
|
|
||
| 標準のシーケンス図が素直に上から下へ流れる記法なのに対し、ZenUML は Java / C# の関数呼び出しに近い中括弧ベースで、条件分岐・並列処理のネストが中に折り畳まれる形になります。`alt ... else ... end` で縦に伸びていく標準記法より、深いネストの構造が把握しやすい気がします。`while` / `par` / `try-catch`、`@Async` / `@Starter` などのアノテーションもあって、非同期フローの表現力でも ZenUML が優位です。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "が" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "が"
- "が"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| 標準のシーケンス図が素直に上から下へ流れる記法なのに対し、ZenUML は Java / C# の関数呼び出しに近い中括弧ベースで、条件分岐・並列処理のネストが中に折り畳まれる形になります。`alt ... else ... end` で縦に伸びていく標準記法より、深いネストの構造が把握しやすい気がします。`while` / `par` / `try-catch`、`@Async` / `@Starter` などのアノテーションもあって、非同期フローの表現力でも ZenUML が優位です。 | ||
|
|
||
| ただし現時点では大きな落とし穴があります。(※2026年5月時点)手元で試した限り、GitHub Markdown も Qiita も ZenUML コードブロックを描画できませんでした(各プラットフォームが内蔵する Mermaid レンダラーが ZenUML 統合のバージョンにまだ追いついていないのが原因のようです)。Mermaid 最大の旨味である「コードブロックをそのまま貼って読ませる」気軽さが失われるので、現時点では ZenUML の採用は見送り、標準の `sequenceDiagram` を使うのが無難、というのが実際に試してみての結論です。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "も" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "も"
- "も"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| 標準のシーケンス図が素直に上から下へ流れる記法なのに対し、ZenUML は Java / C# の関数呼び出しに近い中括弧ベースで、条件分岐・並列処理のネストが中に折り畳まれる形になります。`alt ... else ... end` で縦に伸びていく標準記法より、深いネストの構造が把握しやすい気がします。`while` / `par` / `try-catch`、`@Async` / `@Starter` などのアノテーションもあって、非同期フローの表現力でも ZenUML が優位です。 | ||
|
|
||
| ただし現時点では大きな落とし穴があります。(※2026年5月時点)手元で試した限り、GitHub Markdown も Qiita も ZenUML コードブロックを描画できませんでした(各プラットフォームが内蔵する Mermaid レンダラーが ZenUML 統合のバージョンにまだ追いついていないのが原因のようです)。Mermaid 最大の旨味である「コードブロックをそのまま貼って読ませる」気軽さが失われるので、現時点では ZenUML の採用は見送り、標準の `sequenceDiagram` を使うのが無難、というのが実際に試してみての結論です。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "が" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "が"
- "が"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
| [](https://mermaid.live/edit#pako:eNp...) | ||
| ``` | ||
|
|
||
| 便利な反面、社外秘の情報を扱うなど固くしたい場合は、これらのボタンを押さないといったチーム方針も考えられます。逆に技術ブログなど最初から公開前提の図であれば、mermaid.ink の URL にクエリパラメータを足して画像フォーマットや解像度を調整することもできます。パラメータの詳細は [mermaid.ink の README](https://github.com/jihchi/mermaid.ink) を参照してください。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/ja-no-redundant-expression> reported by reviewdog 🐶
【dict2】 "することもできます"は冗長な表現です。"することも"を省き簡潔な表現にすると文章が明瞭になります。
解説: https://github.com/textlint-ja/textlint-rule-ja-no-redundant-expression#dict2 (ja-technical-writing/ja-no-redundant-expression)
|
|
||
| 完全に閉じた環境で図を画像化したい場合は、CLI の `mmdc`([mermaid-cli](https://github.com/mermaid-js/mermaid-cli))をローカルで回すのが現実的です。 | ||
|
|
||
| おまけで、[Mermaid Chart](https://www.mermaidchart.com/) アカウント(無料)でログインすると、シンタックスエラー時にプレビューエリアに `Fix with AI` ボタンが表示され、LLM に修正案を返してもらえる機能も使えます。GeminiやClaudeなどに直してもらう人が多いと思いますので、利用したいモチベーションは低いかと思いますが、これも Mermaid Chart の LLM 基盤にコードを送信する仕組みです。そのため、Export 系と同じく社外秘の図では使わない方針が固いでしょう。 |
There was a problem hiding this comment.
🚫 [textlint] <eslint.rules.ja-technical-writing/no-doubled-joshi> reported by reviewdog 🐶
一文に二回以上利用されている助詞 "に" がみつかりました。
次の助詞が連続しているため、文を読みにくくしています。
- "に"
- "に"
同じ助詞を連続して利用しない、文の中で順番を入れ替える、文を分割するなどを検討してください。
(ja-technical-writing/no-doubled-joshi)
|
|
||
| TIG(Technology Innovation Group)の真野です。 | ||
|
|
||
| Mermaid.js で図を書こうと [Mermaid Live Editor](https://mermaid.live/) を開いたはいいものの、思いの外色々なボタンがあって機能を使いこなせない!と感じている人も多いのではないでしょうか。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| Mermaid.js で図を書こうと [Mermaid Live Editor](https://mermaid.live/) を開いたはいいものの、思いの外色々なボタンがあって機能を使いこなせない!と感じている人も多いのではないでしょうか。 | |
| Mermaid.js で図を書こうと [Mermaid Live Editor](https://mermaid.live/) を開いたはいいものの、思いの外色々なボタンがあって機能を使いこなせない! と感じている人も多いのではないでしょうか。 |
|
|
||
| 標準のシーケンス図が素直に上から下へ流れる記法なのに対し、ZenUML は Java / C# の関数呼び出しに近い中括弧ベースで、条件分岐・並列処理のネストが中に折り畳まれる形になります。`alt ... else ... end` で縦に伸びていく標準記法より、深いネストの構造が把握しやすい気がします。`while` / `par` / `try-catch`、`@Async` / `@Starter` などのアノテーションもあって、非同期フローの表現力でも ZenUML が優位です。 | ||
|
|
||
| ただし現時点では大きな落とし穴があります。(※2026年5月時点)手元で試した限り、GitHub Markdown も Qiita も ZenUML コードブロックを描画できませんでした(各プラットフォームが内蔵する Mermaid レンダラーが ZenUML 統合のバージョンにまだ追いついていないのが原因のようです)。Mermaid 最大の旨味である「コードブロックをそのまま貼って読ませる」気軽さが失われるので、現時点では ZenUML の採用は見送り、標準の `sequenceDiagram` を使うのが無難、というのが実際に試してみての結論です。 |
There was a problem hiding this comment.
[textlint-fix] reported by reviewdog 🐶
| ただし現時点では大きな落とし穴があります。(※2026年5月時点)手元で試した限り、GitHub Markdown も Qiita も ZenUML コードブロックを描画できませんでした(各プラットフォームが内蔵する Mermaid レンダラーが ZenUML 統合のバージョンにまだ追いついていないのが原因のようです)。Mermaid 最大の旨味である「コードブロックをそのまま貼って読ませる」気軽さが失われるので、現時点では ZenUML の採用は見送り、標準の `sequenceDiagram` を使うのが無難、というのが実際に試してみての結論です。 | |
| ただし現時点では大きな落とし穴があります(※2026年5月時点)手元で試した限り、GitHub Markdown も Qiita も ZenUML コードブロックを描画できませんでした(各プラットフォームが内蔵する Mermaid レンダラーが ZenUML 統合のバージョンにまだ追いついていないのが原因のようです)。Mermaid 最大の旨味である「コードブロックをそのまま貼って読ませる」気軽さが失われるので、現時点では ZenUML の採用は見送り、標準の `sequenceDiagram` を使うのが無難、というのが実際に試してみての結論です。 |
No description provided.